Home |
Rules |
Authors |
Mailing lists |
Menus and hot keys |
Network game |
Command line parameters |
Platform specific issues |
User levels |
Core algorithm |
Source code |
Bugs |
To do |
Copying
To do
Bug-fixing
In its latest releases Liquid War is quite stable IMHO.
However there are still some issues with network under Windows
for instance. I'm aware of these bugs and I'm trying to fix them
but this does really take time.
I always welcome bug-reports and patches, as making Liquid War W 5.x.x as
stable and bug-free as possible is really important to me - and
most of the time players also appreciate stable programs 8-)
Artwork
It's hard to find people to do that kind of thing.
Artists are indeed pretty rare, at least artists who wish to
create stuff freely...
So if you feel like adding some theme support to Liquid War,
this could *really* help.
I used the textures I had but it would be nice
if one could have a "space" ambiance, an "ocean" ambiance
or a "desert" ambiance.
This could really make the game better I think.
Musics (in midi format) are also appreciated.
Tim Chadburn spontaneously contributed the first midi files,
and it really pleased me 8-)
New features
I regularly receive requests for new features in Liquid War.
Of course I do not have enough time to implement them all,
so they land in my "todo" list. However, most "major"
evolutions are now planned for Liquid War 6, since the code
in Liquid War 5 is bloated as hell. It's all right to
debug it and code minor evolutions, but that's all.
However, here's a list of what "could be" in the next
Liquid War 5.x.x releases, although it might never be
implemented there and come later with Liquid War 6:
- Network enhancements. Network in LW5 is somewhat buggy and
hard to use, improvements wouldn't harm.
- Theme support. This would be a way to get rid of the ugly
current fonts and menus.
Liquid War 6
Liquid War 6 *is* planned.
This being said, it's important to note that:
- Not one single line of code has been typed yet 8-)
- Until 6.0.0 is released, 5.x.x remains *the* stable and useable
branch. 5.x.x will be maintained as long as needed and will probably
be maintained (bugfixes I mean) even when 6.0.0 is ready. So if you
want to contribute some maps, graphics, or anything else for the
current 5.x.x branch, don't fear that your work will be lost before
2 months because all interest went off 5.x.x and everyone is using
6.0.0 instead. 5.x.x is here to stay.
- Liquid War 6 will be an almost complete rewrite. I mean that common code
between branches 5 and 6 might end up in representing 0% of the total code.
I think this is a wise decision, for the current code is really hard
to maintain, and would not survive any serious cleanup. LW5 was first written
in 1998, for DOS, when I had much less experience in programming. In 5 years
I - and other people as well - hacked major enhancements in it such as
cross-platform support, network games, and if you compare release 5.0 with the
latest 5.x.x release, you'll see that a bunch of things have changed. I had
never expected I would patch and fix this game for so long, and
it's no surprise that it's bloated today.
- Liquid War 6 won't run on "slow" computers anymore. I mean it will require
some accelerated display (OpenGL for instance) to run. This is IMHO
acceptable since LW5 will remain available. People with slow computers will
always be able to run LW5 instead of LW6. But if some nice fancy features are to be
implemented in 6.x.x, one needs to drop support for low-class machines.
I also plan to use different technologies and languages to code LW6.
As of today, I have a rather precise idea of what tools I'm going to use,
but *before* I really start coding LW6, I'd like to test these tools on
a "real life example". This "real life example" will probably be a rewrite
of the good old HP48 Babal (www.ufoot.org/babal/) for desktop
computers (GNU/Linux and Windows). Here are the tools I plan to use:
- "GNU framework". I mean that I'll try to make LW6 as close as possible
to the GNU standards. This has the advantage that it's then much easier
to make the program operate in a GNU environment. For instance LW6 will
use GNU automake/autoconf, GNU gettext, and have a GNU-ish source tree.
This should save time in the long run, the experience I have on LW5
teaches me that there are a bunch of low-level boring tasks (generating
documentation in several formats, generating source tarballs, handling
i18n/l10n) which are done automatically by GNU tools, and it's a good
idea to re-use other people's work and be standard compliant.
- Standard C language for the core algorithm. This is where I might
use a few dozen lines of code from LW5. C is fast, portable, and
very adapted to this kind of code.
- Assembly for the core algorithm on Intel architectures. LW5 does
this too, and it's even faster than C. However, this assembly code
will be written only when the equivalent algorithm is available
in C. Think of it as an optimization, not as a base component.
- OpenGL display. I'll probably use Glut (www.opengl.org/developers/documentation/glut.html)
which is portable and does enough stuff for me. I do not think I'll need a
wrapper on it and/or a more general library like SDL.
- "mod" music. Let's be clear: MIDI sucks. Well, more precisely, it sucks on
standard desktop computers (the kind of computer everyone uses). Most of
the time mod files sound much better, and have the advantage of sounding the
same on every computer. MikMod (mikmod.raphnet.net) will probably be used.
- Scheme as the glue language for all this. I'll very certainly use
Guile (www.gnu.org/software/guile/guile.html). I'm strongly convinced
that C is absolutely *not* adapted to code large scale programs, unless one
uses an extension language. Guile solves this issue by offering a way to
code some parts in scheme. You might wonder why I do not use another
extension language. The excellent Python language (which I know better than
scheme by now) would be a very good contender for instance. Well, to be
honest, I'm very interested by Scheme and Lisp-like languages in general, and
I've good reasons to think that once I master them, they'll simply be the
languages I prefer. But this is enough Scheme advocacy 8-)
Of course, all this complete rewrite and new tools are not a goal in
themselves. So here's the list of new features which are planned to be in LW6:
- Truecolor support. LW5 has strong color limitations (32 colors, not 32 bits colors but
really *only* 32 colors) for textures and this won't be anymore in LW6.
- Map wrapping/tiling. You could have a map where the right and left border would
"communicate". Any fighter leaving the map on the right side would reappear on the left.
- Several cursors per team. This feature is easy to implement even with the current
algorithm, but isn't possible to implement in a reasonnable time because LW5 is bloated.
LW6 should have it. The fighters would simply follow the closest cursor.
- Fancy multiplayer options such as team alliance.
- Fancy 3D displays. This could be very nice combined with map wrapping/tiling. You could
imagine playing on a sphere, on a tore, on a Moebius ring...
- Maps could be deeper in some places. In a deep place armies would take less surface
but would be stronger.
- Of course, anything that LW5 does (unless maybe running under DOS), LW6 will do it 8-)
- Any idea is welcome! Although I can't garantee all ideas will be implemented,
there are at least more chances that it happens given the fact that LW6
should be much easier to hack and enhance.
So, that's it for LW6 for now. It's still vaporware, but believe me, some day you'll
be able to download liquidwar-6.0.0.tar.gz. Until then, any idea, suggestion or
help is welcome.
This documentation is also available on:
www.ufoot.org/liquidwar.